home *** CD-ROM | disk | FTP | other *** search
/ Megahits 5 / Megahits 5 (1994)(GTI - Rhein-Main-Soft)(DE)(Disc 2 of 2)[!].iso / archive / print / hwgpostbeta6.lha / HWGPOST / History < prev    next >
Text File  |  1994-12-01  |  53KB  |  1,108 lines
  1. #
  2. # $Id: History,v 1.24 1994/12/01 20:36:18 heinz Exp $
  3. #
  4.  
  5. This is the history from the original 1.7 source up to now in chronological
  6. order. Releases follow the changes done:
  7.  
  8.         - took the original 1.7 sources and added my own fixes.
  9.  
  10.     2.0 HWG internal
  11.  
  12.         - SAS/C 6.x compatibility
  13.  
  14.         - Added 24 bit capabilites. Note that any of the 24 plane ptrs can
  15.           be set to NULL to achieve "partial" rendering of bitplanes. This
  16.           way you can render e.g. a 300 dpi A4 24 bit image one plane
  17.           at a time even on a small machine doing 24 passes. Afterwards you
  18.           could combine the planes on HD to a full image. This seems to be
  19.           easier than rendering clips with a depth of 24 bit.
  20.  
  21.         - sethalftonephase.
  22.  
  23.         - integrated Tom Rokicki's fixes.
  24.  
  25.         - handling of illegal type 3 encodings (well sort of).
  26.  
  27.  
  28.     2.1 HWG still not public
  29.  
  30.         - After a virtual memory restore the current font setup was totally
  31.           messed up, which resulted in a invalidfont error in the best case.
  32.           Worse cases were possible.
  33.           I fixed this by removing a few global (Yuck!) font variables and
  34.           integrating them into the graphics state. As a side effect calls
  35.           to show are now faster.
  36.  
  37.         - For errstackoverflow and errdictstackoverflow the stacks were not
  38.           cleared as the should be according to Adobe.  The fix for the
  39.           operandstack is complete. For the dictstack and execstack there
  40.           might be still a problem. I currently have no idea how to solve
  41.           multiple stack overflows and the Adobe manual doesn't really tell
  42.           what should happen if the execution stack runs over its limit.
  43.  
  44.         - For the first time I put it into RCS.
  45.  
  46.     22  HWG still not public
  47.  
  48.         - The new local/global VM scheme seems to be working now.
  49.           The dictstack is like in a level 2 implementation now.
  50.           The overhead needed triggers an increase of memory use of about
  51.           80% for all objects. I don't see a way to reduce this if I want
  52.           to keep going to level 2. No idea yet on how to implement a nice
  53.           garbage collection without adding _major_ overhead to object
  54.           handling. At least a restore does a true memory free now.
  55.  
  56.         - New operators: setglobal, currentglobal, gcheck, scheck,
  57.                          glyphshow, <<, >>, undef, arct,
  58.                          setstrokeadjust, currentstrokeadjust,
  59.                          setbbox.
  60.  
  61.         - Neither setbbox nor the strokeadjust stuff is tested.
  62.  
  63.         - The strokeadjust stuff doesn't really do a decent strokeadjust
  64.           currently. It is more of an experiment right now.
  65.  
  66.         - GlobalFontDirectory is now there, (Shared variant, too).
  67.  
  68.         - putinterval now deals with packed arrays.
  69.  
  70.         - execstack now correctly clears the attributes for all copied
  71.           objects.
  72.  
  73.         - dictionaries conform to level 2 now and expand as needed.
  74.  
  75.         - undef is implemented. It doesn't reduce the dictionary size. It
  76.           just invalidates the entry. (Note: This is not a typenull!)
  77.  
  78.         - null is no longer an operator but a constant.
  79.  
  80.         - The complete system name table according to the adobe reference
  81.           manual appendix F is now implemented.
  82.  
  83.         - The object types are now numbered according to the red book,
  84.           page 113, table 3.14.
  85.  
  86.         - Hashing in nametoken() should be a little faster now.
  87.  
  88.         - clippath will no longer return an empty clipping path. Instead
  89.           it will return a zero area path at (0,0) device space.
  90.  
  91.         - <~ASCII85~> implemented, not tested.
  92.  
  93.         - Some speedups in scantoken.
  94.  
  95.         - Only PaintTypes 0 and 2 are accepted now, not tested.
  96.  
  97.         - CDevProc handling put in, not tested.
  98.  
  99.         - added 'a' and '+' modes to file opening, not tested.
  100.  
  101.         - defineuserobject/undefineuserobject/execuserobject, not tested.
  102.  
  103.         - filter mechanism in place, eexec runs on top of it now.
  104.           dct, ccittfax, and lzw filters missing, proc and string input not
  105.           tried.
  106.  
  107.         - Real BlueValues with a zero fractional part are now accepted to
  108.           allow use of broken fonts.
  109.  
  110.         - /loadfont in init.ps discards garbage on the operand stack left
  111.           by the font.
  112.  
  113.         - filenameforall implemented. I need this functionality for the
  114.           resource ops. Limited testing.
  115.  
  116.         - setobjectformat, currentobjectformat implemented. Not tested.
  117.  
  118.         - error handling should be pretty much level 2 compliant now
  119.           except for "binary" and stackoverflow handling inside the error
  120.           handler itself. Not really tested.
  121.           stackoverflow handling inside the error functions is a nasty one,
  122.           as we don't have Level 2 compliant expanding stacks. This
  123.           actually doesn't matter, as even a "true" level 2 interpreter
  124.           could run out of memory in that situation. It seems to be an
  125.           obscure and undefined case. I handle it my way. At least it
  126.           should not crash.
  127.  
  128.         - character showing could be a little faster now. Hashing for
  129.           it does not need multiplications anymore. It uses shifts and
  130.           additions.
  131.  
  132.         - status should handle a string arg now. Not tested.
  133.  
  134.         - renamefile, deletefile, fileposition, setfileposition
  135.           implemented. Not tested.
  136.  
  137.     22.3 HWG still not public
  138.  
  139.         - callextfunc now no longer public. It is nasty stuff anyway.
  140.  
  141.         - Now the names @vmhwm, @prompts instead of vmhwm, prompts.
  142.  
  143.         - many internal speedups and simplifications. Don Knuth said that
  144.           "premature optimization is the root of all evil.". This is of
  145.           course true, but I mainly cleaned up quite some code to make
  146.           it more readable to me and "reduced" definitely unneeded type
  147.           sizes. The speedups came as a positive side effect, though they
  148.           are probably not that noticeable with standard PostScript code.
  149.  
  150.         - imaging and filling now in separate source files. It was all too
  151.           big IMHO.
  152.  
  153.         - For displays with less than 100 dpi on at least one axis, a
  154.           default halftone frequency of 30 instead of 60 is chosen now.
  155.           This gives at least some halftoning on screen as default which
  156.           makes many pictures look much nicer. I am not sure that this
  157.           conforms to the B&W book where it is said that 60 is returned as
  158.           default, but it gives better results for B.J.User. So what the
  159.           heck ...
  160.  
  161.         - When grestore behaves like a noop because there is nothing to
  162.           restore, the halftone screens are no longer invalidated.
  163.  
  164.         - copy is now level 2 compliant for dictionaries. No attribute
  165.           changes anymore for the destination.
  166.  
  167.         - There was some unlogical code in calclogicaldepth (pun intended)
  168.           which IMHO could have failed under special circumstances. Should
  169.           be safer now.
  170.  
  171.         - When closing an eexec file, the dictstack is popped only if there
  172.           is sysdict on top of it. Anything else is silently ignored to
  173.           avoid recursion caused by the error handler (which can cause
  174.           files to be closed, too).
  175.  
  176.         - Implemented a ForceBold mechanism for type 1 fonts. If
  177.           ForceBold is true and a stem would be rendered 1 pixel wide
  178.           because its width is >= 1.3 and < 1.5 it will be thickened to two
  179.           pixels. 1.3 seems to give visually acceptable results. 1.25
  180.           as limit for rounding up looks pretty unreadable already.
  181.  
  182.     22.4 HWG still not public
  183.  
  184.         - StdXW and StemSnapX implemented. "Snapping" should work when the
  185.           delta to the actual width is less than 1.0 _pixel_.
  186.  
  187.         - Implemented FamilyBlues and FamilyOtherBlues.
  188.  
  189.         - selectfont is now built in and behaves correctly.
  190.  
  191.         - Major rework of the font machinery to help adding the composite font
  192.           extensions. Now most of the vars needed for rendering are cached
  193.           at setfont time. I trade memory for speed.
  194.  
  195.     22.5 HWG still not public
  196.  
  197.         - Moved the ForceBold limit up to 1.4. 1.3 just doesn't look too good.
  198.  
  199.         - Major rework of the font caching. The font cache size can now be
  200.           changed (needed for setcacheparams) and with a tiny little change
  201.           the efficiency of the font cache has gone up it seems.
  202.  
  203.         - Implemented setcacheparams, currentcacheparams.
  204.  
  205.     22.6 HWG still not public
  206.  
  207.         - Setup internals for the implementation of User Parameters. This causes
  208.           changes to VM handling, font handling, and the interpreter stack setup.
  209.           All other values are currently noops.
  210.  
  211.         - currentuserparams, setuserparams, setvmthreshold implemented.
  212.           Currently we don't have any garbage collection. So the value you set with
  213.           setvmthreshold does nothing.
  214.  
  215.     22.7 HWG still not public
  216.  
  217.         - Somewhere in 22.7 I went to SAS/C 6.51.
  218.  
  219.     22.8 HWG still not public
  220.  
  221.         - xshow, yshow, xyshow implemented. Seem to work well.
  222.  
  223.         - missing flush in error message output added.
  224.  
  225.         - rectfill, rectclip, rectstroke.
  226.  
  227.         - half a ton of const keywords added to many functions.
  228.  
  229.         - setgstate, gstate, currentgstate. Not tested.
  230.  
  231.         - forall should no longer enumerate read protected keys.
  232.           I am not exactly sure that this is correct behaviour, though.
  233.  
  234.         - kshow resets the current font after executing the proc if
  235.           necessary.
  236.  
  237.         - findresource will behave as in a "small memory" situation as
  238.           Adobe names it. That is, it will never fiddle with the VM mode
  239.           even for type 3 fonts, unlike e.g. Display PostScript does
  240.           according to Adobe.
  241.  
  242.         - moved definefont and undefinefont over to using resource
  243.           primitives. I don't even know right now if it will compile. ;^)
  244.           Uhm, as you see, undefinefont should be available now, too.
  245.  
  246.         - Implemented @RegisterDiskResource to tell HWGPOST what external
  247.           resources are available.
  248.  
  249.         - findfont is using resources now, too.
  250.  
  251.         - init.ps is setting up the disk resources now!
  252.  
  253.         - eexec should behave like run now. It should automatically close
  254.           the file it creates on EOF _and_ on any other termination! This
  255.           should fix "{eexec} stopped" like constructs which used to leave
  256.           systemdict on the dictionary stack.
  257.  
  258.         - findfont, definefont, and undefinefont are now defined in terms
  259.           of resource operators as described in the R&W book.
  260.  
  261.         - ISOLatin1Encoding, StandardEncoding, and findencoding are now
  262.           defined in terms of resource operators as described in the R&W
  263.           book.
  264.  
  265.         - Split up font handling and show handling even more. Another
  266.           source file postshow.c is now available.
  267.  
  268.     22.9 HWG still not public
  269.  
  270.         - minor cosmetic reworks in some publically visible files
  271.  
  272.     22.10 HWG first public beta release
  273.  
  274.         - currentcolortransfer returned garbage. Should be fixed now.
  275.  
  276.         - Internal preparations for setting up color spaces!
  277.  
  278.         - setcolor implemented. Not tested.
  279.  
  280.         - setoverprint. Note that this is a no op currently!
  281.  
  282.         - currentoverprint.
  283.  
  284.         - created postcolor.c with all the colorspace handling stuff.
  285.  
  286.         - Family[Other]Blues check still had a bug that showed with the "d"
  287.           of the Times-Italic I have here. Should be fixed now.
  288.  
  289.         - I commented out the halftonephase ops for now. This will need
  290.           much work _after_ patterns are done. Any halftonephase != 0 will
  291.           probably slow done rendering a lot then.
  292.  
  293.         - sethalftone, currenthalftone, general halftone dictionary
  294.           support. Not tested at all.
  295.  
  296.         - This just came to mind. Did I mention that the scanner no longer
  297.           uses the isspace() macro, but truly checks according to the R&W
  298.           book specs for white space? This has been in there for quite some
  299.           time.
  300.  
  301.         - Added provision for true CMYK rendering into the bitplanes
  302.           instead of RGBW on the fly. This has actually been done
  303.           earlier already, but now it is enabled. Not tested.
  304.  
  305.         - For the pattern color space, I need a masking feature. So I
  306.           enhanced the device structure to provide for a mask.
  307.  
  308.         - Big problems with the image ops and handling of the Decode array
  309.           fixed. It wasn't decoded correctly anyway and it wasn't used at
  310.           all for gray scale devices.
  311.  
  312.         - A missing flush in effect mixed error output and output
  313.           by e.g. =, ==, pstack in an inappropriate way.
  314.  
  315.     22.11 HWG internal
  316.  
  317.         - /version should be a string now. Sorry for the inconvenience.
  318.  
  319.         - curveto with the same start and end point now works as intended.
  320.  
  321.         - pathforall now copies the path into an internal buffer before
  322.           enumerating it. This way changes to the current path while
  323.           pathforall is active no longer hurt the result.
  324.  
  325.         - Commented out sethalftone/currenthalftone and setcolor for now.
  326.           They are not fully functional yet, and their presence might
  327.           confuse valid PostScript files.
  328.  
  329.         - Serious bug in handling of parameters for the image operators
  330.           resulted in errors for 8 bits per sample. Found this by accident
  331.           only. :-(
  332.  
  333.     22.12 HWG release for NOVA.
  334.  
  335.         - True halftone phase support is back. It should be general enough
  336.           to be a base for patterns. Rendering of halftone screens is
  337.           slower now than before. I might add a special optimized halftone
  338.           function for standard filling though that runs fast for any x
  339.           shift of 0 or by a multiple of 8 pixels.
  340.  
  341.         - Fixed a bug that could possibly mess up halftoning for very
  342.           small vertical rendering. Never noticed this though.
  343.  
  344.         - Added deviceinfo to make /processcolors in statusdict easier.
  345.           processcolors has been added, too (In init.ps!). Why I did this
  346.           now? I just got news about /processcolors and before I forget
  347.           about it, I add it.
  348.  
  349.         - Bookman-Light showed me a possible problem with eexec decoding.
  350.           Though I think that Bookman-Light actually violates type 1 font
  351.           specs, I added special code to the file handling to work around
  352.           the problem for IBM font style binary encoded eexec portions.
  353.           The above is a euphemism for "hack added to make ugly stuff
  354.           work".
  355.  
  356.           Note: Anyone complaining about a font not working is required to
  357.                 provide me with a legal copy of the font for my own use
  358.                 from now on. Argh!
  359.  
  360.           Sidenote: Bookman-Light 001.003 is buggy according to Adobe. In
  361.                     001.004, the problem is supposedly fixed.
  362.  
  363.         - Work on Separation/Indexed colorspaces to get all the interfaces
  364.           for patterns set up. Tricky and not yet visible to the user.
  365.           Probably not for a while.
  366.  
  367.         - To get best performance and memory use for any halftoning or
  368.           patterns, you should have a width of the cell that is a multiple
  369.           of eight device pixels. Any halftone phase other than a multiple
  370.           of eight will slow down cell rendering. Any width other than
  371.           a multiple of eight will (sometimes considerably) increase memory
  372.           use. This is especially important for users of halftone
  373.           dictionaries. The cell will be replicated in x direction until a
  374.           byte aligned width is achieved. So e.g. for a 9 pixel wide cell,
  375.           the actual internal width and memory requirement will be 9 * 8 ==
  376.           72 pixel per line, which can be evenly divied by 8. If I did not
  377.           do it like that, rendering would not take long, but forever.
  378.           Actually it is not a new invention. The default halftone screens
  379.           always did it like that. I used this for halftone screens
  380.           specified via dictionaries only, and I have reason to assume that
  381.           I'll need it for patterns.
  382.  
  383.         - eexec reworked again. It now uses a destructor to pop the system
  384.           dictionary. The file handling is back to normal. No strange stack
  385.           handling within closing of files anymore. I feel that this is
  386.           good news.
  387.  
  388.         - Interesting enough, the eexec rework led me to a problem with the
  389.           implementation of resource ops while debugging. Tricky
  390.           manual stack manipulation after a resource op caused an error
  391.           could cause a crash. Should be robust now.
  392.  
  393.         - setdevparams, currentdevparams. They are dummies that don't do
  394.           very much. setdevparams will always give an error and
  395.           currentdevparams returns an empty dictionary.
  396.  
  397.         - Reworked halftone validating mechanism in my quest for patterns.
  398.           I made it look more "black box" for the callers which should help
  399.           me a lot in the future. As a side effect a few unnecessary
  400.           invalidations of halftone screens could be removed.
  401.  
  402.         - Color handling behaves better now, too. Setting a colorspace and
  403.           setting the colors is much cleaner internally now and colors will
  404.           be only set once not twice for every colorspace/color change. Oh
  405.           well. Not exactly true. sethsbcolor will first set the colorspace
  406.           and with that the initial color, and then the requested hsb color
  407.           will be set. That is what you get for using strange stuff.
  408.  
  409.         - I'll have to design a general bitmap caching scheme within the VM
  410.           handling. This will cover hopefully characters, patterns, and
  411.           forms. Maybe I can even do something about user paths then, but I
  412.           doubt it. While thinking about this and looking at the current
  413.           font cache handling, I could fix a possible hole in font type
  414.           checking and improve VM efficiency with save/restore
  415.           combinations. Strange how things hang together sometimes.
  416.  
  417.         - For the Pattern color space, the font cache will be ignored. A
  418.           rendering function would be needed that I am not willing to
  419.           design to support rendering of the font cache in any reasonable
  420.           way. So with patterns all characters will be rendered the slow
  421.           way.
  422.  
  423.         - The interrupt signals will be checked now in '=', '==', and in
  424.           'pstack'. While doing this, I added correct defines for the
  425.           signals to postlib.h. I added defines for the garbage collection
  426.           that does not yet exist, too.
  427.  
  428.         - Changed style of error display to something supposedly much more
  429.           Adobe like.
  430.  
  431.         - Changed rounding factors for setstrokeadjust to 0.25, i.e. I use
  432.           the 1/4 method suggested in "PostScript by Example". Should give
  433.           slightly better results. Why didn't I think of that in the first
  434.           place?
  435.  
  436.         - Interesting enough there was a bug in VM save/restore handling.
  437.           restore would not correctly restore things in all circumstances
  438.           because marking of allocations was off by one.
  439.  
  440.         - Handling and closing of the currentfile was not exactly "ok". It
  441.           should work better now, and currentfile should never return
  442.           "wrong" file handles. Uhm well, if no file exists, currentfile
  443.           will return %stdin to return something. There is not really a
  444.           concept of an invalid file object.
  445.  
  446.         - There should no longer be any "hanging" file open calls when an
  447.           error occurs. When a file is closed, it is closed now. No fake
  448.           close handling anymore to keep the interpreter happy. I
  449.           originally missed a paragraph in the R&W book saying how it works
  450.           and messed it up. Now it is done right (I hope).
  451.  
  452.         - Time for a freeze.
  453.  
  454.     22.13 HWG internal
  455.  
  456.         - Threshold halftoning was ... uhm ... totally broken. It should
  457.           work now. This paragraph doesn't tell how much time I spent on it.
  458.           As a positive side effect of the rework, the halftone cache is
  459.           now smarter. Going from black to white shold be as fast now
  460.           as going from white to black when asking for halftones.
  461.  
  462.         - sethalftone is now available.
  463.  
  464.         - Still a "typo" in the new error message format corrected.
  465.  
  466.         - There could still be "hanging" file open calls when the execution
  467.           stack was popped, e.g. on error or quit. Now any files
  468.           encountered while popping the execution stack will be closed.
  469.           This should help a lot.
  470.  
  471.         - Note: kshow does not create a loop context currently! I'll fix
  472.           this when I am into composite fonts. I'll need to invest some
  473.           thought into this. Colorspaces are still first on my list.
  474.  
  475.         - BTW, if you guys out there want CIE color spaces, buy a decent
  476.           book on the subject, and send it to me. The R&W book isn't all
  477.           that clear, and afterall it would be nice if I didn't have to
  478.           spend all my money on this. :-) If nothing like this happens, CIE
  479.           color spaces won't come soon.
  480.  
  481.         - In systemdict you will now find /=string with a length of 128.
  482.  
  483.         - Added the destructor concept to vm restore handling to make cache
  484.           flushing independent of vm handling.
  485.  
  486.         - name table handling is now more black box, too. I need all this
  487.           black box handling to implement the new general caching scheme.
  488.           A small change to the hashing in name token seems to have helped
  489.           lookup performance.
  490.  
  491.         - Added @calluserhook. Not tested yet.
  492.  
  493.             mark <args> <hookadr> <msgadr> @calluserhook
  494.  
  495.             ==>
  496.  
  497.             mark <resargs> <resint>
  498.  
  499.           ints, reals, bools, or strings may be used as args with a maximum
  500.           number of 8 arguments. The values are put into an array of longs
  501.           that is passed as object address to the hook. For strings two
  502.           slots in the array are used for address and length. On return the
  503.           values of ints, bools, and reals will be copied back into the
  504.           internal PS objects. The called function runs on the context of
  505.           post.library and might need to set up A4 from e.g. hook->h_Data
  506.           to make use of its local near data segment. No assumptions may be
  507.           made about post.library's context! It is private stuff!
  508.  
  509.           All this should help people needing to interface to external code
  510.           a lot.
  511.  
  512.         - The new general caching scheme is in place now. While it has more
  513.           overhead than the old font cache, there does not seem to be a
  514.           performance hit as hashing and caching is a little smarter.
  515.  
  516.         - For blue values any reals are now accepted and converted to
  517.           integers.
  518.  
  519.         - Some cleanup to the font and show handling for the new caching
  520.           scheme.
  521.  
  522.         - exit always had a bug. It would look below the lower end of the
  523.           exec stack. One object too much. Ouch.
  524.  
  525.         - kshow now has a loop context that can be exited via exit. I don't
  526.           have composite fonts yet, sorry.
  527.  
  528.         - While testing pattern generation, I found that gstate object
  529.           handling was in fact totally broken. The paths were not saved
  530.           correctly. This works now. Otherwise patterns would not work.
  531.  
  532.         - Patterns seem to work now. Please note that patterns are sort of
  533.           slow to render because there is a lot of work to do for this
  534.           including floating point calculations when a cached pattern is
  535.           imaged onto the page. Patterns are also memory hungry. If you know
  536.           the bounding box in device space (i.e. in pixels of the
  537.           bitplane!), you can estimate how much memory patterns eat. They
  538.           use bitplanes in the size of the bounding box. One mask bitplane
  539.           is always needed and for colored patterns you'll need one
  540.           pattern bitplane per device bitplane. Currently there is no
  541.           setsystemparams call and the maximum amount of bytes for the
  542.           pattern cache is ~60K. As we don't have a garbage collection yet,
  543.           allocated memory for the pattern cache will stay allocated until
  544.           it is either reused or invalidated by a VM restore.
  545.  
  546.         - Hopefully not too many bugs lurk inside pattern handling. BELIEVE
  547.           ME, PATTERNS ARE TRICKY TO HANDLE!
  548.  
  549.         - As I said above, drawing characters with patterns does not use
  550.           the font cache and probably never will. It is slower of course
  551.           but it works the same and doesn't add tons of special handling
  552.           to rendering.
  553.  
  554.         - Corrected a sign bug that messed up 360 degree arcs with arcn.
  555.           This one has been in there since at least 1.7. I found this while
  556.           testing patterns.
  557.  
  558.     22.14 HWG the pattern freeze.
  559.  
  560.         - The band rendering operators are now named "@currentband" and
  561.           "@setband". To keep compatibility to old post.library usage, I
  562.           added a kludge to init.ps to define the old names in terms of the
  563.           new names. Using the old names is strongly discouraged, though!
  564.  
  565.         - Oh well, I forgot to mention that the masking feature contained
  566.           in the struct PSextdevice works and may be used. If it wouldn't
  567.           be working, patterns would not work at all.
  568.  
  569.         - An interesting comment on the side is that the interpreter source
  570.           is still fairly portable even with those many changes. So if I
  571.           was ever to find a computer with a better OS than the Amiga, I
  572.           could take the interpreter with me. Don't fear anything, though.
  573.           There isn't any better OS around for me as far as I can see.
  574.  
  575.         - Cleaned up names for extended PSsignalint() flags.
  576.  
  577.         - Added missing PSerrstr prototype and pattern cache default sizes.
  578.  
  579.     22.15 HWG
  580.  
  581.         - Just found a bug when testing the release version. Font caching
  582.           would not work correctly.
  583.  
  584.         - I totally forgot to mention that XUID's should work for fonts and
  585.           patterns.
  586.  
  587.     22.16 HWG Pattern Release BETA2
  588.  
  589.         - resourcestatus did not update the operand stack correctly. So you
  590.           did not get the expected results.
  591.  
  592.         - Negative setdash offsets should work now and give results that
  593.           make some sense.
  594.  
  595.         - In some cases there was too much clipping done when rendering
  596.           images. The bug was in there at least since post 1.7.
  597.  
  598.         - Some PS files are checking /version and replace buggy operators
  599.           depending on this information. Of course HWGPOST does not have
  600.           any bugs, ;^) so I had to rework the "version"/"revision" setup.
  601.           /version is now an arbitrary number (50) and /revision is derived
  602.           from the library version number. For HWGPOST 22.16 it is e.g.
  603.           22016. Suggestions for a better /version choice are welcome.
  604.  
  605.         - A comment on pattern rendering. Due to the current imaging model,
  606.           a pattern must be cacheable. Patterns that do no fit into the
  607.           pattern cache will cause an error. In addition to this behaviour
  608.           the "MaxPatternItem" user parameter is not checked currently.
  609.  
  610.         - The image operators had some bugs. The first one had been in
  611.           there since the beginning of time. It caused placement and sizing
  612.           problems with images by one pixel. They were due to a
  613.           misinterpretation of filling rules for image data. This should be
  614.           fixed now. Images are now much more handled like standard fills
  615.           which makes handling them a lot safer and clearer.
  616.           The second bug had been introduced by me when the new rendering
  617.           scheme for patterns was put in. Untransformed images that map to
  618.           the page in a 1:1 scale were not at all rendered. The best one
  619.           could hope for was a gray or white area in the image's size.
  620.           Actually this bug was the major reason to work towards a beta 3
  621.           really soon, because not fixing it would have made the beta 2 for
  622.           e.g. "dvips" applications or faithful bitmap rendering useless.
  623.  
  624.         - If a disk resource is not registered, the /ResourceFileName entry
  625.           in the implementation dictionary is now checked if available. The
  626.           implications of this feat are staggering. ;^) Transparent
  627.           adaptive resource lookup by checking different paths is now
  628.           possible via /ResourceFileName. This makes for nice font lookup.
  629.           Note that this obviously can't affect resourceforall because
  630.           there is no way for this operator to "guess" where a
  631.           /ResourceFileName implementation would look and what resoure
  632.           names would be appropraiet for filenames found. So resourceforall
  633.           will only return registered resources. I doubt that there is a
  634.           good way to implement a general file search for resourceforall
  635.           that could handle e.g. all the different styles of font names
  636.           possible and all sorts of different directories. While
  637.           directories could be handled via a "path" concept, alias names
  638.           for fonts cannot. They needed to be registered. In this case one
  639.           could register the font directly anyway so there is nothing lost
  640.           by the current implementation. A special HWGPOST feature is that
  641.           /ResourceFileName may return a zero length string. This counts as
  642.           "not available/known". It not only speeds up processing a little
  643.           but provides for a more "natural" error handling.
  644.  
  645.           Net result is, that findresource might be able to find things
  646.           that resourceforall does not list, if /ResourceFileName is used.
  647.  
  648.         - For the daring: I put in some code into the image handling to
  649.           support 12 bits per sample. Not tested at all yet. Anything can
  650.           happen.
  651.  
  652.         - Added rootfont. Until composite font support is done, it will be
  653.           in effect equivalent to currentfont.
  654.  
  655.         - Nobody ever noticed it before, but the scanner had a limited
  656.           understanding of the "newline" concept when skipping comment
  657.           lines.
  658.  
  659.         - defineresource sets the /Category entry properly now.
  660.  
  661.         - While resource file stunts can be played now via
  662.           /ResourceFileName, this alone would be rather cumbersome. An
  663.           internal resource lookup scheme is now implemented that makes
  664.           defining a search path for any type of disk based resource rather
  665.           easy. Resource lookup is now done like this:
  666.  
  667.             1. When registered use the registered filename. Done.
  668.             2. Check if (%ENV%HWGPOST/PATH_<category>) exists. If so:
  669.                 a) Parse this file for prefix/suffix combinations to try
  670.                    on the resource name. If a filename can be generated
  671.                    where the file exists, consider the resource to be
  672.                    found. Use this filename. Done.
  673.             3. Check /ResourceFileName if available. Use any non zero
  674.                length return string as filename. If so, done.
  675.             4. Fail. The resource can't be found if you get this far.
  676.  
  677.           A demonstration PATH_FONT file to be copied into
  678.           (%ENVARC%HWGPOST) is supplied. Refer to it for further
  679.           information.
  680.  
  681.           As with /ResourceFileName, there is no support for resourceforall
  682.           because there does not seem to be a way to revert back to
  683.           resource names when scanning directories.
  684.  
  685.         - As you can see, HWGPOST makes use of environment variables for
  686.           the first time, now. They'll all be in a subdirectory "HWGPOST"
  687.           to keep them in one place.
  688.  
  689.     22.17 HWG
  690.  
  691.         - I postponed the beta 3 release to implement resource file
  692.           lookup into resourceforall, too. resourceforall will now check
  693.           the environment variable (%ENV%HWGPOST/PATH_<category>) just like
  694.           findresource. On any resourceforall call, all supplied path
  695.           prefixes and suffixes will be scanned with a PostScript file
  696.           pattern of (*) to enumerate all possible files. Then a list is
  697.           built of all the filenames stripped down by the length of the
  698.           prefix and suffix to give resource names suitable for
  699.           findresource. resourceforall will then continue to work as usual,
  700.           enumerating local and global resources. Then the preregistered
  701.           disk resources will be enumerated and finally the entries in the
  702.           just scanned resource file list.
  703.  
  704.           This new behaviour has some side effects and consequences. the
  705.           file scan cannot check the contents of the file. So any file
  706.           encountered within the resource path will be listed as available
  707.           resource, whatever it is. So keep your resource directories CLEAN
  708.           and put only resource files there. Otherwise you might confuse
  709.           PostScript programs using resourceforall to do more than just
  710.           enumerating resource names.
  711.  
  712.           There is no serious duplicate checking while building the file
  713.           list. So if you have the same font file names in different
  714.           directories listed in the path, chances are high that they are
  715.           both listed.
  716.  
  717.           Another side effect is that resources with a name longer than the
  718.           filesystem supports cannot be listed correctly without
  719.           preregistering them. Consider this example:
  720.           (HelveticaNeue-UltraLightItalic) can be
  721.           (HelveticaNeue-UltraLightItal) to a filesystem, because the
  722.           maximum filename length is exceeded. While preregistering the
  723.           full resource name with the partial filename will solve this
  724.           problem for findresource, the automatic lookup via the path will
  725.           not give usable results. The disk scan will return the incomplete
  726.           filename as resource name.
  727.  
  728.           So if you use the new path environment variables:
  729.  
  730.             1. Watch out for filenames that are too long. Preregister those
  731.                resources.
  732.             2. Watch out for non resource files that might get in the way.
  733.             3. If you do need alias names, use filesystem hardlinks to make
  734.                them.
  735.  
  736.           Of course resourceforall still can't handle any tricks that you
  737.           might want to play via /ResourceFileName. But this shouldn't be a
  738.           limitation and /ResourceFileName stunts should not be necessary
  739.           anymore anyway. I discourage using /ResourceFileName now.
  740.  
  741.           I put so much "automatic lookup" into the resource mechanism that
  742.           anyone who wants to complain about missing features should have a
  743.           _very_ good reason to bother me.
  744.  
  745.           NB: Playing these stunts wasn't exactly easy. So if you want to
  746.               do something good for me in return, buy a "Sonata" music font
  747.               as gift and send it to me. I'd have good use for this font.
  748.  
  749.         - Illegal type 3 encodings that do not use names should work again.
  750.  
  751.           NB: This violates Adobe specs, and I will not guarantee that
  752.               these illegal encodings continue to be accepted.
  753.  
  754.     22.18 HWG beta 3 release
  755.  
  756.     22.19 HWG
  757.  
  758.         - Changes to the library setup code to make an easy name change to
  759.           e.g. "hwgpost.library" possible.
  760.  
  761.     22.20 HWG hwgpost.library special release
  762.  
  763.         - Due to a rather reasonable problem report, I decided to put
  764.           "callextfunc" back in. It is now there as "@callextfunc" in
  765.           disguise with some better setup work for the called function.
  766.           Note that I still discourage any use of this function. Let me
  767.           point again to @calluserhook. See HWGPOSTlib.doc for details.
  768.           This stuff needs to be tested.
  769.  
  770.         - All the composite font stuff is in now. Rather limited testing.
  771.           Nested composite fonts not tested at all because I don't have any.
  772.           Actually I don't have any composite fonts, just the one I hacked
  773.           up myself for testing. Some FMapTypes tested, some not. I need
  774.           examples and feedback here. I wouldn't mind you guys filling up
  775.           my font library in exchange for giving you these features.
  776.           I still hope to find a Sonata font in my smail eventually, too.
  777.  
  778.         - rectclip did not do a newpath.
  779.  
  780.         - execform is now available. Due to memory considerations, no
  781.           caching is currently done.
  782.  
  783.         - The image operators should finally take files as data sources.
  784.           While this is currently rather slow, at least it seems to
  785.           work quite well. So don't complain. I might eventually get around
  786.           to improve it a lot, but without incentive to do so, not much will
  787.           happen here.
  788.  
  789.         - There wasn't a chance that the image operators worked with 12 bit.
  790.           Now there is. Note that image rendering is slower now because
  791.           of this. Also a one color image source wasn't working correctly
  792.           with a non gray colorspace. While rendering images takes now
  793.           twice as much memory (8 bytes * pixels per page line), all sample
  794.           mangling problems should be solved now. Also the Indexed color
  795.           space should now be usable with the image operators.
  796.  
  797.         - Interesting enough it seemed that arrays in global VM could
  798.           potentially still be affected by save/restore combinations. Due
  799.           to changes in the VM system for implementing startjob, this
  800.           should never happen again.
  801.  
  802.         - The interpreter checks for abort signals now while doing image
  803.           data processing. Helps a lot with stopping unwanted 1MB images
  804.           coming in via files and filters. ;^)
  805.  
  806.         - Added a UseStdIO option to the post frontend. If you use it, post
  807.           will use its own standard shell console filehandles and pass them
  808.           to the library as standard I/O instead of using the interactive
  809.           window of the screen display. Note that the interactive window
  810.           will still be opened. It won't be used for I/O though.
  811.  
  812.         - Somewhere along the lines I had changed frontend behaviour to
  813.           open a screen if neither iff, screen, nor printer was specified.
  814.           Now the old behaviour of doing a silent "printer" is back.
  815.           Also using the BW/RGB/CMYK gadgets was broken.
  816.  
  817.         - =string should behave like in Adobe implementations now.
  818.  
  819.         - Changed the default prompt to "PS>".
  820.  
  821.         - Added startjob, PSFLAGJxJOBSERVER. Changed the meaning of
  822.           PSFLAGSAVE.
  823.  
  824.           The new meaning of flags for PSintstring():
  825.  
  826.             PSFLAGSTARTJOBSERVER:   force a successful startjob with
  827.                                     a "false" operand before interpreting
  828.                                     the file or string.
  829.  
  830.             PSFLAGENDJOBSERVER:     force a successful startjob with
  831.                                     a "true" operand after interpreting
  832.                                     the file or string. This works like a
  833.                                     major cleanup.
  834.  
  835.             PSFLAGSAVE              Do both of the above.
  836.  
  837.           With PSFLAGSAVE you can easily run many encapsulated jobs. With
  838.           the other two flags you can do multiple calls to PSintstring()
  839.           for one job. You have to use PSFLAGSTARTJOBSERVER on the first
  840.           call and PSFLAGENDJOBSERVER on the last call to PSintstring()
  841.           then. You can't nest this and you should not make any special
  842.           assumptions.
  843.  
  844.           startjob won't work if the PSFLAGSAVE or PSFLAGSTARTJOBSERVER
  845.           have not been used since the setup or the last PSFLAGENDJOBSERVER
  846.           or PSFLAGSAVE. That is, the current context must support job
  847.           encapsulation.
  848.  
  849.         - Under rather peculiar circumstances the halftone mechanism failed
  850.           because of a loop check that could be wrong by one. If the
  851.           internal halftone memory needs met in a specific, rather
  852.           complicated way with the HT memory size and the previous memory
  853.           use up to that point, a wrong cache screen was generated. Just
  854.           another variation of the "0 to n" instead of "0 to n-1" problem
  855.           that has been in there since pre 1.7 days.
  856.  
  857.         - serverdict and exitserver are now built in.
  858.  
  859.         - statusdict is built in and some of the init.ps statusdict
  860.           operators are built in now, too. Note that this stuff is
  861.           implementation dependent and that I might do what I want with it.
  862.           So you better adhere to Adobe specs and forget about statusdict
  863.           as far as possible.
  864.  
  865.         - When the first init file is run, the default VM allocation mode
  866.           should be local now for sure. This should make many applications
  867.           a lot safer.
  868.  
  869.         - user object functions now do better type checking.
  870.  
  871.     22.21 HWG The "startjob" version
  872.  
  873.         - Major rework of all stack access code. This will make it easier
  874.           to possibly add dynamic stack sizing and some other internal
  875.           stuff and while it seems totally unrelated it might come in
  876.           handy for a future setpagedevice. As a side effect the library
  877.           seems to be faster for most non rendering operations. These
  878.           changes affected most of the sources though, so they classify as
  879.           ENORMOUS REWORK. It seems right now that I did not break
  880.           anything, but we'll see about that.
  881.  
  882.     22.22 HWG The "new stack stuff" release
  883.  
  884.         - rectclip still did not work right. It set the clipping path
  885.           correctly and then just cleaned it out again. Hmpfh.
  886.  
  887.         - A document created by the Interleaf publisher showed me that
  888.           currentfile must return a literal file object. Since the
  889.           beginning of time it had always returned an executable file
  890.           object. A nice guy from Adobe confirmed this change to be the
  891.           right thing to do.
  892.  
  893.         - Cleaned out some confusing code in the interpreter loop.
  894.  
  895.         - Note that the systemparam operators are _very_ rudimentary and
  896.           mostly noops. They are not fully implemented yet and the stuff
  897.           implemented is only to make startjob/exitserver basically
  898.           possible. I plan to fix this for the next public release.
  899.  
  900.         - Scanning of <~ASCII85~> was broken. Should be working now.
  901.           Implementing the ASCII85 filters stil has to wait a little,
  902.           though.
  903.  
  904.         - If the image operator data sources where prematurely exhausted,
  905.           the operand stack wasn't cleaned up correctly. Tss. Always the
  906.           image operator.
  907.  
  908.         - Prepared for true 8 bit CMYK handling by adding new bitplane
  909.           pointers. A depth of up to 32 should now be ok. One problem with
  910.           all this depth stuff is, that I can only test gray scale
  911.           rendering with other depths than one with reasonable ease. As my
  912.           A3k is ECS, I can only check on 1 bit per color RGB or CMYK
  913.           displays. As the shading and rendering for multiple colors is
  914.           absolutely identical to the calculations for a one color display,
  915.           this should theoretically not be a problem. If you experience any
  916.           problems with more than 1 bpc and RGB or CMYK displays, _you_
  917.           need to help me. I can't afford to buy an AA machine or a
  918.           graphics card + monitor.
  919.  
  920.         - Moved path handling and matrix calculations into own source files.
  921.           gstate handling is something really strange. I'll need to clean
  922.           this up for pagedevice handling.
  923.  
  924.         - Added a debugging command to help all those with strange rendering
  925.           problems: @dumprenderinfo. This command will put out on %stdout
  926.           some information about what any rendering with the current gstate
  927.           values would do to the planes. If you have any rendering problems
  928.           that you can't solve, I will need the output of this command to
  929.           help you!
  930.  
  931.         - Added some safety checks to color and shade handling that should
  932.           indicate if something goes wrong without hurting performance.
  933.           This is just paranoia though. Nothing actually went wrong yet.
  934.  
  935.         - Added HWGPOST_DEVB_INVERTOUTPUT. This inverts all shades before
  936.           setting up rendering into bit planes. What does this mean?
  937.           Without this flag a 100% color value (e.g. white) will cause 0
  938.           bits in the planes and 0% color (e.g. black) will cause 1 bits.
  939.           This choice had been made because typically there is less black
  940.           on a page than white, and setting bits is generally more time
  941.           consuming than zeroing out memory. This is kind of ugly though
  942.           for color rendering because one needs to set up an "inverted"
  943.           color table. With the new flag all output shades x are converted
  944.           into "1.0 - x" before they are used for rendering. This in effect
  945.           will cause a negative image where 0% color will cause 0 bits.
  946.           The hacked post frontend got an InvertOutput option to test this.
  947.  
  948.     22.23 HWG The "better graphics" release
  949.  
  950.         - If one specified a 0 to 360 degrees arc (a circle), the last
  951.           point generated would be a in effect postitioned in a position >
  952.           360 degrees which was "beyond" the first point. A closepath would
  953.           cause a path segement then working backwards which messed up the
  954.           join at this point because the joining mechanism (correctly) made
  955.           a join for a ~180 degree turnaround. You could notice this for
  956.           stroked full arcs with big linewidths when the arc did not seem
  957.           to be correctly closed. The bug was due to additive rounding
  958.           errors inside arc generation which made it exceed the 360 degree
  959.           limit internally by a rather tiny fraction. Can't happen anymore.
  960.  
  961.         - The hex and rle filters do a read ahead for EOF now to make
  962.           them work better with image ops. I'll have to implement this
  963.           for filters in general though to be R&W book compliant.
  964.  
  965.         - I decided to make this available as beta 4 now, even though
  966.           I haven't finished the setsystemparams implementation as I
  967.           originally planned to do. It'll be in the in the beta 5.
  968.           Sorry.
  969.  
  970.     22.24 HWG beta 4 release
  971.  
  972.         - I have been working on a datatype for HWGPOST based on an
  973.           idea by Swen K. Stullich. As his code was not usable for me
  974.           at all, I wrote new stuff. The data type handles PS
  975.           recognition via "%!" and renders the picture in B&W. It also
  976.           tries to obey any BoundingBox or Orientation header comment.
  977.  
  978.         - The library now understands how to handle DOS EPS files with a
  979.           binary header. It will automatically read the PostScript code
  980.           embedded. This is not a performance hit for normal files except
  981.           for the first character read from a file. In fact, true ASCII
  982.           files should be read slightly faster than before now.
  983.           Why this before setsystemparams? To be able to enhance the
  984.           datatype now which seems to have more appeal.
  985.  
  986.         - The simple HWGPOST datatype knows about DOS EPS files now. It
  987.           will now try to display something even if the [E]PS files did not
  988.           have a showpage. It also has much more robust PS file
  989.           recognition. Thanks to Tony for the push to make this
  990.           better.
  991.  
  992.         - The library should no longer behave strange if you pass NULL
  993.           filehandles. Note that it was _never_ acceptable to pass NULL
  994.           filehandles to the library for %stdin, %stdout, and %stderr.
  995.           It is still not acceptable. This is only a kludge to make broken
  996.           SW work right.
  997.  
  998.         - With this entry, I break the magic 1k line History mark.
  999.  
  1000.             "Eine Flasche Sekt!"
  1001.  
  1002.         - The internal definefont handling did not allow multiple keys per
  1003.           font dictionary as possible in Level 2. Fixed.
  1004.  
  1005.         - cvi and cvr are now a little less strict about input. They should
  1006.           handle one trailing space now. This is an important change and
  1007.           fixes some documents.
  1008.  
  1009.         - Added some very heavy magic to fix stone age FreeHand documents
  1010.           that break documented Level 2 compatibility. I sure hope I got
  1011.           this right. It seems to work though.
  1012.  
  1013.         - datatypes.library seems to presort the filetypes in some
  1014.           arrogant way without regard to the descriptor files. This
  1015.           always messed up handling of the datatype descriptor. I
  1016.           could not figure out the exact problem. Annoyed as I was, I
  1017.           took the brute force approach and use two descriptor files.
  1018.           One for ASCII files, and one for binary files.
  1019.  
  1020.         - The datatype no longer has problems with negative values in the
  1021.           bounding box comment. It also stops scanning when it finds an
  1022.           %%EndComments. It also sets up the color map correctly, so that
  1023.           clips out of multiview will now show up in a nice and colorful
  1024.           way instead of black.
  1025.  
  1026.         - The datatype behaves _much_ better now in low memory
  1027.           conditions.
  1028.  
  1029.         - The datatype now optionally handles color displays,
  1030.           densities and other default sizes. How? Via a new
  1031.           environment variable: "ENV:HWGPOST/DATATYPECONFIG"
  1032.  
  1033.           The first line of this environment variable is evaluated in
  1034.           DOS ReadArgs() style with this template:
  1035.  
  1036.               COLORS/K/N,BPC/K/N,XDEN/K/N,YDEN/K/N,DENSITY/K/N,
  1037.               DEFWIDTH/K/N,DEFHEIGHT/K/N
  1038.  
  1039.             COLORS:     Either 1 or 3. Only B&W or RGB supported!
  1040.             BPC:        Bits per color. Anything from 1 to 8. Note
  1041.                         that BPC*COLORS must be <= 8 or strange things
  1042.                         may happen due to the OS limit of 8 bitplanes.
  1043.             XDEN,YDEN:  Densities (dpi). Default is 75 dpi.
  1044.             DENSITY:    Convenience operator to set both densities.
  1045.             DEFWIDTH,
  1046.             DEFHEIGHT:  If no bounding box is specified in the file,
  1047.                         these values are used. You need to specify
  1048.                         them in units of 1/100 inch though, not in
  1049.                         1/72 inch like PostScript likes it. The
  1050.                         default values for these parameters will give
  1051.                         an A4 like bitmap size.
  1052.  
  1053.            This environment variable should do the job for a while.
  1054.  
  1055.         - Tricky behaviour change to make library use for programmers
  1056.           easier. It has always been permissible to set the kill flag on
  1057.           the copypage/showpage callback to abort the interpreter run
  1058.           synchronously. showpage will now skip the erasepage if it finds
  1059.           the kill flag set. Thus it is possible now to abort the library
  1060.           run on a successful showpage without the need to redefine
  1061.           showpage or copy the bitmap away into some backup place to save
  1062.           it from being erased. Nifty, eh?
  1063.  
  1064.         - even better protection against endless error looping now.
  1065.  
  1066.         - interesting enough the SAS/C 6.51 floor() and ceil()
  1067.           implementations in scm881.lib will crash when you pass a 0
  1068.           NaN to them. This could happen if someone caused the CTM to
  1069.           be a e.g. 0 matrix. Then matrix inversions would give NaN
  1070.           results which killed the interpreter immediately due to the
  1071.           SAS/C bug. I put in some protection into the most relevant
  1072.           floating point calculations to circumvent this problem.
  1073.  
  1074.         - The post frontend should accept negative values in the SIZE
  1075.           option now.
  1076.  
  1077.         - Ouch. Due to the internal changes done for the beta 4, the
  1078.           PSsetdevice() interface broke completely. No workaround for
  1079.           the beta 4. Fixed now. Sorry.
  1080.  
  1081.         - Magic added for default font lookup. If the search for a
  1082.           font fails, the interpreter will try to find
  1083.           /@DefaultFontName as font. The updated init.ps shows how to
  1084.           define a dummy default font. If you like any other font as
  1085.           default font, e.g. /Courier, just set /@DefaultFontName to
  1086.           /Courier.
  1087.  
  1088.     22.25 HWG beta 5 release
  1089.  
  1090.         - pathbbox returned garbage for rotated coordinate systems. Why
  1091.           didn't anyone (including me!) notice this before? This must have
  1092.           been a problem for a long time. This will be the reason for
  1093.           a beta 6 to come out RSN.
  1094.  
  1095.         - Color values out of range should now be silently adjusted as
  1096.           described by the R&W book.
  1097.  
  1098.         - The datatype did not compute width and height of the bounding box
  1099.           correctly. It does now, though it won't handle "(atend)".
  1100.  
  1101.         - The datatype will give an error message now instead of an error
  1102.           number.
  1103.  
  1104.     22.26 HWG beta 6 release
  1105.  
  1106. *** EOT ***
  1107.  
  1108.